home *** CD-ROM | disk | FTP | other *** search
-
-
- PROBLEMS.DOC
-
- Matthew Dillon
- 891 Regal Rd.
- Berkeley, Ca. 94708
- USA
-
- uunet.uu.net!overload!dillon or
- dillon@overload.Berkeley.CA.US
-
- CED
-
- Those of you using the CED editor need to use the sticky option.
- Unfortunately, CED requires that STICKY be the last argument so
- what you really need to do is set the editor command in UULIB:Config
- to execute a script file that runs CED with the filename and STICKY
- option.
-
- The format for CED is: CED file -sticky
-
- A script file can be found in UUCP:SC/UUCed
-
- MODEMS AND GETTY
-
- There are several possible sources of problems in setting up
- UUCP. The major problem areas in order of likelyhood are
- listed below:
-
- (1) The modem is expecting a protocol that Getty has not
- been told to use (XON/XOFF, 7WIRE, none)
-
- If the modem uses 7-wire use the -7 option for Getty, else it is
- assumed the modem uses no protocol. Normally you specify -7 but
- the modem will probably work just fine whether you specify it or
- not.
-
- (2) The modem does not hangup when DTR is dropped
-
- All modern modems hangup when DTR is dropped. Usually a dip switch
- enables/disables the option. If it is impossible to drop a
- connection by dropping DTR you can use the -d0 option to make Getty
- use the +++ sequence. This only works if you do not specify a dumb
- modem in the -M option.
-
- NOTE: older versions of the A2232 multi-port serial.device do not
- drop DTR when the device is closed. There is no way to drop DTR
- with these devices.
-
- When you cannot use DTR to drop a connection you must use the -d0
- option so Getty will use +++ ATH0 instead.
-
- (3) The modem does not understand simple AT commands or does
- not generate a CONNECT message.
-
- If the modem does understand dropping DTR but does not understand
- simple AT commands or generate a CONNECT message use -c0 -Md (no
- connect msg and dumb modem). In this case the baud rate must be
- known and specified with one or more -B options. When no CONNECT
- message is available Getty does not know what the connect baud rate
- actually is. It will begin by trying the first -B option and
- switch to the next whenever a line-break is received.
-
- (4) Baud rate problems
-
- The default modem type when no -M option is specified for Getty is
- a hays modem. If you have a multimodem you can use -Mm and the
- baud adjust options for Getty. Normally you specify a -B option
- for each baud rate the modem is capable of connecting at. If the
- modem generates a CONNECT message you need only specify one -B
- option that is used to reset the modem and Getty will automatically
- handle the CONNECT messages.
-
- If your modem always talks to your Amiga at a given baud rate no
- matter what the CONNECT message says then use a single -B option to
- specify that baud rate then the -A option which tells getty to
- ignore any baud rate specified in the CONNECT message.
-
- (5) GETTY CRASHES or FREEZES, TERMINAL PROGRAMS or UUCICO FREEZES
-
- Due to bugs in the serial.device, it is possible that Getty
- and/or another program using the serial.device while Getty is
- active will crash or freeze.
-
- To get around these problems you MUST use the -d0 option to
- disconnect (+++ sequence), both for Getty and for UUCico.
-
- OUTGOING CALLS
-
- Unfortunately Getty handles only incomming calls. UUCico deals without
- outgoing calls itself. Currently you must specify the proper baud rate
- in the L.Sys file for uucico to work properly. UUCico currently ignores
- any connect message.
-
- Disconnecting will work the same way Getty handles it. If there is no
- Getty running disconnecting works by dropping DTR.
-
-
- NEWS
-
- RNews supposedly takes less memory now. It still takes quite a
- hunk and you may run out, which will cause queue files to be
- left in your spool directory and possible temporary files in
- your news directory.
-
- POSTING NEWS
-
- If your feed does not accept posted articles there are two possible
- problems.
-
- (1) you have set your timezone incorrectly, not likely but at least
- one person has done that.
-
- (2) The feed does not accept the ordering of the news headers, meaning
- it is probably running outdated news software. Currently no solution
- for this but I am making an attempt to organize headers such that
- older software will accept them.
-
- MAIL ADDRESSES
-
- If you have problems queuing mail check your L.sys file. Try emailing
- to the adjacent node directly. E.G. if you can connect to 'foo' try
- emailing a test message to 'foo!postmaster'. If you do not wind
- up with three queue files in UUSPOOL: then your L.sys file
- probably has a corrupted entry for foo. Whenever you email to somebody
- three files should end up being added to UUSPOOL: and whenever you
- UUCico to a given machine the spool files in question should be deleted
- as they are sent. When UUCico receives mail from the remote machine it
- will download the remote queue files to UUSPOOL: then uuxqt them. That
- is, the remote queue files should will be placed temporarily in
- UUSPOOL:, unpacked with rmail and placed in UUMAIL:, then deleted.
-
- The most common of all problems is an address like this:
-
- a!b!c!d!e!user%g
-
- In UUCP land this means: a->b->c->d->e->g->user
-
- In ARPA land this means: g->a->b->c->d->user
-
- To get around the problem you must determine the proper sequence
- and convert the address to SOLELY bang-paths (!). DMail has a
- special variable ('help set' from dmail) that specifies fields to
- find the return address in which may be helpful. For especially
- strange addresses you may have to look at the mail headers with
- the 'h' command from dmail.
-
- REMOTE SHELL STARTUP
-
- You can cause Getty to start up a remote CLI with the following entry:
-
- <login>,<password>,<gid-dummy>,0,(AuxShell),ram:,execute uucp:sc/UUShell
-
- where uucp:sc/UUShell is a simple script file.
-
-
-